A Survey on Blockchain Interoperability: Past, Present, and Future Trends
はじめに
2章、5章が議論のメインになっているのでおすすめ
まとめ
先にまとめます。CosmosやPolkadotだけがInteroperabilityではありません。
技術的な相互運用性とデータ的な相互運用性があり、前者をTechnical interoperability、後者をSemantic interoperabilityと呼ぶ
共通点は「ブロックチェーン分野の発展のために、ある程度互換性を持たせよう」ってとこで、それを実現するための手段として多くの解決策が議論されています。
なので、Ethereum2.0みたいに、ある程度の方向性がなく、研究者が好きに開発してるのでカオスです。
プロトコルとコンセンサスを整備するのが主な課題
クロスブロックチェーン取引は、信頼できる第三者の参加なしには実際には実現不可能
プロトコルとして、CBCPもしくはCCCPが必須条件となる
CCCPは既存のBCで実現できる
CBCPは既存のBCを他のBC適応させる必要がある
ネットワーク、コンセンサス、コントラクト、アプリケーション層など、いくつかの層をリファクタリングする必要がある
流行りのソリューション
Blockchain conectors...CCCP→CBCP方法
Blockchian Engine...元からCBCPな方法
1.イントロ
特になし
2.背景
技術用語
ソースチェーンとターゲットチェーン
Source BlockchainとTarget Blockchainがあり、Source Blockchainは、取引が開始されたブロックチェーンで、Target Blockchain上で実行されるようになっています。
CCCP
Cross-Chain Comunication Protocol(CCCP)は、CC-Txを正しく同期させるために、ブロックチェーンのペアが相互に作用するプロセスを定義しています。従って、CCCPは、同種のブロックチェーンが通信することを可能にします。
ex:SideChainは通常CCCPを使用します。
ex:Zendooはビットコインのようなブロックチェーンシステム間の通信を可能にする
CBCP
Cross-Blockchain Comunication Protocol(CBCP) は、CBCPは、CB-TXを正しく同期させるためにブロックチェーンのペアが相互作用するプロセスを定義します。従って、CBCPは、異種ブロックチェーンが通信することを可能にします。
ex: the Interledger Protocol は、プロトコルを実装したブロックチェーンが「お金のパケット」を交換することを可能にする
サードパーティの必要性
CCCP と CBCP の区別は重要である。
CCCP は通常、相互に動作するブロックチェーンの構成と機能を活用することができる。
CBCPは通常、ブロックチェーンを適応させる必要がある。
→つまりブロックチェーンの相互運用性を高めるためには、CBCPもしくはCCCPが必須条件となる
"非同期CCC (クロスチェーン通信プロトコル)に悪さをするノードに対しての耐性があるものは存在しません。"
公正交換問題の削減 を用いて、正しいクロスチェーンコミュニケーションは公正な交換の問題と同じくらい難しいと考えれる。
→「信頼できる第三者がいないと、不正な動作をするノードに対して寛容なCCCプロトコルは存在しない」
信頼できるサードパーティは、中央集権型でも分散型でもよい
中央集権化された信頼された当事者は、例えば、信頼されたバリデータ
分散化された信頼された当事者(バリデータ)は、コンセンサスアルゴリズムを介して、参加者のグローバルな台帳の状態が合意された別のブロックチェーンでもよい。
→しかし、信頼された当事者は、大多数の参加者が誠実であることを保証し、プロセスの正しさを保証しなければならない
→したがって、クロスチェーンプロトコルは"信頼できる第三者のための抽象化として、分散台帳のコンセンサスを使用する"。
“lemma of rooted blockchains”
ソースブロックチェーンがターゲットブロックチェーン上のデータの存在を検証することができないこと
特に、ソース・ブロックチェーンはターゲット・ブロックチェーンのコンセンサスを模倣する必要があり、
さらに、ターゲット・ブロックチェーンのブロック履歴の（潜在的に大規模な）サブセットを保存しなければなりません。
トラストアンカー
ブロックチェーン内で資産を移動させることを考えれば 真のブロックチェーン相互運用性は不可能だと主張しています
しかし2つの台帳を持つブロックチェーンは相互運用性の可能性を提供しています
クロスブロックチェーン取引は、信頼できる第三者の参加なしには実際には実現不可能です。
そのため、トラストアンカー、すなわち信頼できる第三者を選択しなければなりません。
言い換えれば、信頼の前提はpermissionネットワークからnon-permissionネットワークまで大きく異なるが、クロスブロックチェーン取引、およびクロスチェーン取引は、基礎となるプロトコルの正しさを保証するために、信頼された第三者を必要とする。本論文で紹介するほとんどのソリューションは、少なくとも1つの分散型トラストアンカーを提示します。
機関ごとのインターオペラビリティの定義
Vernadat
"エンティティ（ソフトウェア、プロセス、システム、ビジネスユニット...）間の相互運用を実行する能力の尺度。この課題は、これらのプロセスやユニット間のコミュニケーション、協力、調整を容易にすることに依存しています。"
Abebe
「異なる台帳間のセマンティックな依存関係を、妥当性を保証した上で、データや価値を転送または交換すること」
NIST
"区別可能なブロックチェーンシステムの構成であり、それぞれが独自の分散データ元帳を表し、原子的なトランザクションの実行が複数の異種ブロックチェーンシステムにまたがっている可能性があり、あるブロックチェーンに記録されたデータが、意味的に互換性のある方法で、他の可能性のある外部のトランザクションによって到達可能で、検証可能で、参照可能である。"
Pillai and Biswas
"クロスコミュニケーションは、他のブロックチェーンシステムに直接状態を変化させることを意図したものではありません。その代わりに、クロスコミュニケーションは、自身のネットワーク内で操作を実行することが期待される他のシステムの機能のいくつかのセットをトリガーする必要があります。"
Hardjono
"トランザクションの完了を達成するために関与するブロックチェーンシステムから独立したアプリケーションレベルのトランザクションの確認(サブトランザクションで構成される)
この人何言ってんの???
インターオペラビリティの3領域
ブロックチェーンインターオペラビリティは3つに分けられる
異なるブロックチェーン間の相互運用性
同じブロックチェーンを使用したdApps間の相互運用性
ブロックチェーンと他の技術の相互運用性（企業システムとの統合など）
用語の補強
CC-Tx
クロスチェーン・トランザクション（CC-Tx）は、「CC」がクロスチェーンを、「Tx」がトランザクションを意味します。
同じブロックチェーンシステム（同種ブロックチェーン）に属する異なるチェーン間のトランザクション
例えば、EVMベースのブロックチェーン間での取引などです。我々は、CC-TX、チェーン間トランザクション、およびブロックチェーン間トランザクションの用語を互換的に使用しています。
CB-Tx
クロス・ブロックチェーン・トランザクション（CB-Tx）とは、異なるブロックチェーン（異種ブロックチェーン）間のトランザクションのことです。
例えば、Hyperledger FabricとBitcoinの間のように。
CC-dApp
Cross-Chain Decentralized Application (CC-dApp)はCB-Txをビジネスロジックに実装するDappです
我々は、用語CC-dAppとCB-dAppを互換的に使用しています。
CCなのにCB?
IoB(この論文独自の定義)
ブロックチェーンのインターネット(IoB)とは、「同質、異質な分散化されたネットワークが、価値のクロスチェーン取引を促進するために通信する」システムである
BoB
Blockchain of Blockchains (BoB)という用語は、いくつかの文書と簡単な説明にしか出てきません。
Verdianらはこの概念を用いて、異なるブロックチェーンのブロックを「メタブロック」に集約し、ポゼット（部分順序集合）と全順序理論を用いてコンセンサスメカニズムで整理し、BoBを生成する構造を説明しています。
BoBとIoB
これらの著者の影響を受けて、我々は、コンセンサスプロトコルが、複数のブロックチェーンに分散したCC-dAppsに属するトランザクションのセットを含むブロックを整理するシステムとして、BoBを定義する。
このようなシステムは、様々なブロックチェーン上でトランザクションを発行している当事者に説明責任を与えるとともに、基礎となる各ブロックチェーンの全体的で更新されたビューを提供するものでなければならない。
したがって、IoBという概念はブロックチェーン間の接続性を前提としているのに対し、BoBという用語は、クロスブロックチェーンのトランザクションを検証できるアーキテクチャを指します。
*IoBに包含されている訳ではない
NSB
CC-Tx、ひいてはCC-dAppsを可能にするために
複数のブロックチェーンの状態を全体的に見ることができるブロックチェーンであるnetwork status blockchainという概念
NSBは、関係するブロックチェーン上で実行された行動の証明（すなわち、トランザクションの送信）と、それらのトランザクションの状態を格納します。
https://gyazo.com/dc9be16a6b1ec02457f34144c4ebfa3b
Fig.3は、ブロックチェーンの相互運用性に関するさまざまな概念の関係を示しています。
CC-dApp は、BoBアプローチを実現します。
このアプローチは、ブロックチェーンが要求するsemantic interoperability（すなわち、値レベルの相互運用性に対応したデータの意味の伝達に関わる）を提供することができます。組織は、アプリケーション層によってマッピング可能ですが、ブロックチェーンのネットワークであるIoBの存在に依存しています。
IoB はtechnic interoperabilityに依存しています
CC-dAppのコンテキストではCC-Txはクロスチェーン・dAppプロトコルによって順序付けられます
このようなプロトコルは、可能な限りトランザクションのアトミック性を保証し、同種ブロックチェーンと異種ブロックチェーンの両方で発生するトランザクションのコンフリクトの可能性を解決しなければなりません。
IoB トランザクションは、CBCPを介して配信され、それによってtechnic interoperabilityを付与し、CC-dApps を可能にします。
研究中に遭遇したいくつかの定義から、私たちはブロックチェーンの相互運用性を次のように想定しています。
「source blockchainがtarget blockchainの状態を変化させる能力のことで、CC-TxまたはCB-Txによって、同種および異種のブロックチェーンシステムの構成にまたがるIoB」
BoBアプローチは、クロスブロックチェーンのdAppプロトコルによって実現され、CCTxのセットに対するコンセンサスを提供し、CCdAppを可能にします。
IoBもBoBもCC-dAppを可能にする
AS
このアーキテクチャ は、自律システム（AS）（またはルーティングドメイン）とゲートウェイを中心とした概念です。
ルーティングドメインは、ネットワーク 管理ドメインの下で、特定のルールで動作するエコシステムです。
ASは、ブロックチェーンネットワークにマップされた単一の管理ドメインを形成するIPネットワークのセットです。
ゲートウェイは、異なるAS内のネットワーク間の通信を可能にするために、クロスドメインルーティングをサポートします。
ゲートウェイは、スマートコントラクトや信頼できるサードパーティなどの相互運用性をサポートするノードです。
私たちの提案は、これまでの研究に影響を受けています。特に、私たちは、各ブロックチェーンを自律的なシステムとして想定しています。パブリックおよびプライベートブロックチェーン上のほとんどのノードは、相互運用性ゲートウェイとしての役割を果たすことができます。ブロックチェーン間の通信を容易にするために、オラクル、ブロックチェーン、およびそれらのコンポーネント（スマートコントラクト、証明書局など)を識別し、アドレスを指定することができる分散型ブロックチェーンレジストリに頼ることができますパブリックブロックチェーンとプライベートブロックチェーンの両方のレジストリは、強力なセキュリティ(例えば、高度な分散化)の下、パブリックブロックチェーンで書かれる可能性があります。あるいは、レジストリの内容は、主要なブロックチェンのステークホルダーによって維持されるカスタムのパブリックブロックチェーンに記録されるか、あるいは信頼されたハードウェアによって強制されます。分散化されたレジストリは、分散化されたドメイン名システムとして機能しますが、代わりにブロックチェーンのためのドメインを使用しています。分散型ブロックチェーンレジストリについての更なる議論は今後の作業に委ねます。このレジストリはオプションであり、IoBを有効にするためには必須ではありません。
https://gyazo.com/ac06aa5bf5976e56c9857bbe1f6779d5
図 4 は、技術的な相互運用性を実現する IoB のアーキテクチャを提案したものです。
この図では BoBを表現していますが、この段階ではアーキテクチャの詳細は省きます。
BlockchainAとBlockchainBは、いずれもパブリックなEVMベースのブロックチェーン、すなわちEthereumとPOA NetworkでBlockchainDおよびBlockchainEはプライベートなブロックチェーン、すなわちHyperledger FabricおよびQuorumです。
ステップ１
Ethereumネットワークに属するブロックチェーンノードであるBlockchainAは、その通信エンドポイント（すなわちIPアドレス）をブロックチェーンレジストリに登録します
ステップ２
その後、ビットコインであるBlockchainCに属するノードのアドレスを検索します。
ステップ３
ＣＣＣＰとＣＢＣＰのプロトコルは、一方向または双方向の相互運用性を提供することができます。
ステップ３において、ＣＢＣＰは、一方向的にEthereumノードとBitcoinノードとの間の通信を確立しているが、これは
EthereumノードはBitcoinのブロックヘッダを読み取ることができるが、その逆はできないためです。
ステップ4と5
BlockchainD と BlockchainE は異種であるため、CBCP によって接続されています。
CC-dAppはすでにblockchainCとblockchainDに接続されており、ブロックチェーン・レジストリでアドレスを取得した後、さらにblockchainEに接続します。
ステップ4は、プライベート・ブロックチェーンにアクセスするために必要な資格情報を作成することで補完することができます
ステップ6
CC dAppプロトコルは、エンドユーザーがブロックチェーンC、ブロックチェーンD、ブロックチェーンEを利用してセマンティックな相互運用性を実現することを可能にします
これらのステップは、ブロックチェーン間の接続性を達成し、それによってIoBを形成し、それによってBoBを可能にする。
CCCPとCBCPは、ブロックチェーンレジストリによってアドレス指定可能なブロックチェーンネットワーク間のエンドツーエンド通信を管理するために採用されます。
このようなプロトコルは、標準化を介して、将来のブロックチェーンのためにシームレスな相互運用性を提供することができますが、それらは既存のブロックチェーンと互換性がありません。
既存のブロックチェーンは、ネットワーク、コンセンサス、コントラクト、アプリケーション層など、いくつかの層をリファクタリングする必要があります。
https://gyazo.com/4a4d50ecb9e1da6b7fa33570bddf1bd2
Fig.5では、提案されたアーキテクチャに対応するブロックチェーン相互運用性の層を、以下を用いてモデル化しています。
ブロックチェーン相互運用性、技術的相互運用性、意味的相互運用性は、ビジネスプロセスである「IoB」と「BoB」が持つ能力である（異なるレベルでの相互運用性を可能にする）。
"クロスチェーン・プロトコル "と "クロスチェーン・ダップ・プロトコル "は、"クロスチェーン・トランザクション "機能を実現するアプリケーション・コンポーネントである。
その他の相互運用性の層は今後の作業に残す。
採用されている相互運用性ソリューションに関わらず、ネットワーク層はリファクタリングに悩まされる可能性が高いです。
トランザクションのファイナリティが異なるブロックチェーンが存在するため、結果的にコンセンサス層になります。
トランザクションの確定性は、確率論的なものと決定論的なものがあり、トランザクションに関与する当事者がそれを
ブロックチェーンにコミットされています。
例えば、Bitcoinは、高い確率で最終的なトランザクションを考慮するために約6つの確認済みブロックを必要とするのに対し（確率論的）、Tendermintのトランザクションは実行直後に最終的なものとなるのに対し（決定論的）、Tendermintのトランザクションは実行直後に最終的なものとなる。
他のブロックチェーンからのトランザクションを含むいくつかの抽象化は、コントラクト層に実装することができます。
これらの変更はアプリケーション層にも影響を与え、より複雑な操作を処理できるようになりました。
アプリケーションは、いくつかの作品で示されているように、クロス・ブロックチェーン・トランザクションをディスパッチするためのAPIを公開することができるようになりました。
データ層は必ずしも変更する必要はありません。
これは実行可能な解決策になるかもしれませんが、運用中のすべてのブロックチェーンを調整して
ブロックチェーン間プロトコルの特定のセットと、それらの異なるレイヤーを適応させることができます。
このソリューションは実際には実現不可能であるため、少なくとも短期的には、ブロックチェーン相互運用性ソリューションは、一般的に特定のブロックチェーンまたは特定のブロックチェーンのセットに合わせて調整されます。
とはいえ、技術が成熟するにつれ、ブロックチェーンの相互運用性の標準が技術的な努力の指針となり、ブロックチェーン空間内での相互運用性に向けた収束につながると信じています。
本稿では、ブロックチェーンに依存しないソリューションや具体的なソリューションを紹介し、議論していきます。
3. 方法論
ブロックチェーン相互運用性は活発に開発されているが、学術的な研究はまだ少ない。
主な議題は以下の3つ(６章で答え合わせするので割愛)
$ 1What is the current landscape concerning blockchain interoperability, both from the industry and academia?
(業界的、学術的に見るとブロックチェーンの相互運用性に関する現在の状況は、どんな感じ?)
$ 2Is the set of technological requirements for blockchain interoperability currently satisfied?
(ブロックチェーンの相互運用性のための技術的な要件は、現在のところ満たされているか？)
$ 3Are Survey on Blockchain Interoperability: Past, Present, and Future Trends
(ブロックチェーンの相互運用性から来るバリューチェーンを可能にする実際のユースケースはあるのか？)
4. 関係ある論文について
インターオペラビリティに関する論文がどのくらいあるか、どのような内容について議論してあるかをまとめた章
気になるトピックを探すにはこの章を参照するとよさげ。(割愛)
5 現在のソリューションについて
この章ではブロックチェーンインターオペラビリティソリューションを以下の表のように分類し概説している
https://gyazo.com/681c5b272908f77e60d624f64a945f4c
5.1Cryptocurrency-directed interoperabilityapproaches
5.1.1SideChain
SideChain（またはセカンダリチェーン、またはリレーチェーン）とは、2つの既存のブロックチェーンが相互運用し、
(例えば、ブロックチェーンのシャーディングを介して）スケーリングし、アップグレードするためのメカニズムです。
メインチェーンは資産の台帳を維持し、クロスチェーン通信プロトコルを介してメインチェーンに接続された別のシステムであるサイドチェーンに接続されています。
例としては、メインチェーンとサイドチェーンの間で資産を転送するためのメカニズムである2-Way Pegがあります。 サイドチェーンは、メインチェーンが互いにサイドチェーンになり得るので、必ずしも「二次的な」ものではありません。
メインチェーンはCCCPを介してサイドチェーンと通信します。ここで両方のチェーンの機能性を考慮する必要があります。
サイドチェーン設計の基本的な構成要素
メインチェーンのコンセンサスプロトコル
サイドチェーンコンセンサスプロトコル
CCCP
https://gyazo.com/491917a4f7c907645c89b7ea6b4f207d
図7はサイドチェーンシステムを示しています。
relayersと呼ばれるパーティは、メインチェーン(ビットコインネットワーク)のブロックヘッダを追跡しています
ビットコイン取引は、スマートコントラクトで検証するために提出されます。
ブロックヘッダが検証されると、relyayeには報酬が支払われます。
最後に、検証されたビットコインのトランザクションは、サイドチェーン内のスマートコントラクトに中継され、例えば、他のブロックチェーン上のトークンを発行することができます。ブロックチェーンのヘッダーを追跡し、Ethereumのスマートコントラクトを介して送信するプロセスをCCCPと考えることができます
https://gyazo.com/bf4542541a072d3fb9bc0fc9c40363ee
SideChainは表3のように細かく分類されます。以下に概説します
5.1.2Notary Schemes
Cryptocurrency-directed interoperabilityapproachesの二つ目
Notary Schemesは、クロスチェーントランザクションのタスクを簡素化します。
しかし、多くの場合、トラストアンカーは中央集権的な当事者（暗号通貨取引所など）に置かれます。
サイドチェーンとは逆に、Notary Schemesはブロックチェーンの拡張ではなく、サードパーティのソフトウェアがブロックチェーン上で操作を行うものです。
このような進化にもかかわらず、一般的に使用されているNotary Schemesは、中央集権型のクリプトカレンシー取引所
（例：Binance、Coinbase、BKEX、LBank、Bilaxy、BitForex）です。
ほとんどの取引所は、執筆時にCryptoCompareによってリストされている分散型の取引所に対して、中央集権化されています。
https://gyazo.com/665b3d149bdc69290461af9509024ae1
図８は、ユーザが中央集権的な取引所を介して暗号通貨を取得するタスクを表している。
ユーザは、不換通貨でクリプトカラ ンスを購入し、購入した資産は、取引所が所有するそれぞれのウォレット、すなわち、カストディアル・ウォレットとも呼ばれる取引所に入金される。
取引所は、このような暗号通貨をネットワーク上で直接、あるいは仲介業者を介して取得し裁定取引サービスを提供しています
https://gyazo.com/3b8302b4806622bde0a2937eccc1b53e
分散型取引所は、ハッシュ化されたタイムロック、または他の技術を用いて実装することができ、これを介して取引を行う場合、ユーザは通常、 中央集権型の取引所に内在する単一障害点を取り除くため秘密鍵を公開しないで済みます。
Agent Chain
Agent Chainは、マルチシグネチャースキームを用いてブロックチェーン間で資産を交換することを目的としたプロジェクトです。 トレーダーは保有する資産をAgentChainにマッピングし、複数の取引オペレーターを1つの取引グループにまとめます。
そのグループのメンバーはマルチシグネチャを使ってアカウントを生成し、資産を含む預金プールとして機能します。
トークンはその後ロックされます。悪質な取引グループが発生した場合の仲裁メカニズムが導入されています
5.1.3 Hashed Time-Lock
Cryptocurrency-directed interoperabilityapproachesの3つ目
ハッシュ化されたタイムロックス契約(HTLC)は、チェーンをまたいだアトミックな操作を可能にするため、当初は中央集権型取引所に代わるものとして登場した。HTLCs の技術は、ハッシュロックとタイムロックを使用して、通常は 2 つの当事者間でアトミックな操作を強制する。
トレーダーは、タイムアウトの前に暗号証明を相手に提供することで、取引を行うことをコミットする。
このスキームでは、1 つのハッシュロックのみに依存して、複数の出力（複数の支払いなど）を作成することができます。
HTLCは、ビットコインでは条件付きの支払い、またはAtmic Swap（またはアトミッククロスチェーンスワップ）のようなクロスチェーンの支払い（Bitcoin-Ethereum）に使用されています。
Atmic SwapはHTLCs技術のサブセットであり、クロスチェーン交換を可能にします。
Atmic Swapは、ユーザーが別のブロックチェーン上で保持されている別の暗号通貨と引き換えに、ある量の暗号通貨を別のユーザーに送ることを可能にします。
https://gyazo.com/af10cf77ea3b254b9b1fe1edb3cbce9c
5.1.4 Hybrid Solution
Cryptocurrency-directed interoperabilityapproachesの4つめ
このカテゴリは、暗号通貨関連資産の相互運用性のための新しいアプローチに関するものです。
分散型秘密鍵方式などがあります。
分散秘密鍵方式は、ユーザや組織の秘密鍵の配布に依存しています。つまり、各秘密鍵を分割することで
これは、複数の当事者間で資産の制御を分散させることにつながる。このようなスキームは、decentralized 2-wayPegだけでなく、decentralized notariesを実装するために使用することができる。
他のアプローチでは、スマートコントラクトに依存して、サイドチェーンとエスクローパーティに基づくプロトコルを組み合わせています。
エスクロー(escrow)は、第三者が2つの当事者間の取引または取引グループを規制する取り決めです。
エスクローは通常、取引の担保となる当事者の一方からの資産（例えば、クリプトカレンシー）を保持します（貸し手の利益を保護するために借り手が質権を設定した資産）。
5.1.5 Discussion on Cryptocurrency-Directed Approaches.
Cryptocurrency-directed interoperabilityapproachesの5つめ
クリプトカレンシーを中心としたアプローチについての議論
我々が提示したいくつかのソリューションでは、ビットコインがEthereumのサイドチェーンであること、および/またはEthereumが独立しているにもかかわらず、ビットコインのサイドチェーンであることを考慮していることに注目したい。
許可されたブロックチェーンを指向したサイドチェーンプロジェクトは
スケーラビリティの向上と機能開発をさらに助けることができる
サイドチェーンのセキュリティが侵害されると、攻撃者は悪意のある行為をメインチェーンに伝搬させることができず、望ましい分離が可能になります。
https://gyazo.com/2498e84c829ce25d50c4176942220528
表3(再掲)は、我々が調査したサイドチェーンソリューションをまとめたものです。
ほとんどのリレーがEthereumで展開されており、サイドチェーンのコンセンサスメカニズムを持っている
BTC Relayのような他のチェーン上の取引を検証する単純なリレースキームは、情報の流れが一方向的であるため、サイドチェーンコンセンサスを必要としません。
LiquidとPOAも同様のアプローチをとっています。彼らの信頼されたフェデレーションは、信頼されたハードウェアを使用して、スマートコントラクトを実行し、取引を検証を行っています。
しかし、サイドチェーンにも問題がある。
一方のチェーンがコンセンサスに達するのが遅いコンセンサスアルゴリズムを使用している場合、他方のチェーンで取引が発生したかどうかを確認するのに時間がかかり、資産の流動性を低下させる可能性がある。
Federated 2-Way Pegにおける中央集権化が存在する傾向がある。
トラストアンカーは、資産交換という望ましい機能を実現する1つ以上の主体に置かれている。したがって、談合の可能性を減少させるために、異なるインセンティブを持つ異なる利害関係者を持つことが重要である。
複雑なアプリケーションを作ることが難しい
SideChainは通常、ペギングメカニズムの条件を指定するための任意のコードを許可しないため、開発者に複雑なアプリケーションを開発する権限を与えないため
攻撃者がCenterized 2-Way Peg(または連合型の双方向ペグに属するエンティティの集合)の秘密鍵の制御を得ることができれば、ユーザから資金を盗むことができる。。
Notary Schemes
Notary Schemesが ブロックチェーン上で取引を行い、その情報を他の人に転送することができます。
Notary Schemesのコンソーシアムを作ることで、より分散化を図ることができますが、それでも中央集権的なアプローチと考えられています。クリプトカレンシー指向のカテゴリーのNotaryのほとんどは、中央集権的な取引所です。
https://gyazo.com/665b3d149bdc69290461af9509024ae1
https://gyazo.com/3b8302b4806622bde0a2937eccc1b53e
図8と図9は、それぞれ中央集権型取引所と分散型取引所でクリプトカレンシーを購入するトレーダーを表しています。
中央集権型取引所には は、分散型取引所に比べて市場シェアの大部分を占めています。
これは、中央集権型取引所がエンドユーザー（投資家、投機家、クリプトカレンシー専門家）にサービスを提供しているためであり、プラットフォームの弾力性に特に関心がない一方で、分散型取引所はより良い取引手数料とセキュリティを提供する傾向があります。
したがって、セキュリティのための快適さとスピードはトレードオフにある。
要約すると、「Notary Schemesはブロックチェーン間の仲介者」です
両方のチェーンでスマートコントラクトのロジックを捕捉しなければならない。
価値レベルと機械的レベルの両方の相互運用性の全範囲を捕捉することができますが、使用例は主に暗号通貨交換のためのものであるため、ソリューションとして最も適切なものではない
Hashed LTime Look Contracts(HTKLC)
https://gyazo.com/af10cf77ea3b254b9b1fe1edb3cbce9c
表 4 (再掲)は、本調査で提示された様々な HTLC のソリューションを示している。
HTLC は、異なるブロックチェーン間のAtmic Swapを可能にし、双方向の支払いチャネルに資金を供給する。
HTLC は互いに後から連結することができるので、取引当事者間に直接の接続がなくても取引が可能になる。
プログラム可能なエスクローとして機能するため、最も信頼性の高い実用的なアプローチ
しかし、ハッシュ化されたタイムロックは、クロスブロックチェーンの資産移転を発行するトレーダーが特定の条件(暗号資産の為替レートなど)でしか秘密を提供しない可能性があるため、資本の保持や不公平な取引につながる可能性がある
Atmic Swapは大量採用には障害となります。
各Atmic Swapは複数の取引を必要とし、待ち時間が長くなるため
https://gyazo.com/5d5eb8868393e7a94f7b6ce8fd5ab3af
Liquid、RSK、POA Networkのようなソリューションは、バリデーターの信頼モデル（つまり、ユーザーはネットワークを制御するバリデーターのセットを信頼しなければならない）を与えられたクロスチェーン資産交換を提供しています。
最後に、信頼性のない資産交換を実現するために異なるメカニズムを使用するカテゴリを提示しました。
表5は、このサブカテゴリを示している。
このようなメカニズムは、インセンティブメカニズム、スマートコントラクトベースのエスクロー と、資産を管理する秘密鍵をシャーディングすることで、相互運用性を実現しています。
XClaim と DeXTT は、それぞれ、暗号通貨を裏付けとした資産やクレーム・ファースト・トランザクションのような革新的な概念に基づいて、相互運用性のためのメカニズムを提供しています。
どちらのスキームも、相互運用性を保証する当事者 (XClaim ではredeemerと裏付けbacking vault、DeXTT ではdeterministic witnesse) が適切であるという前提の下で動作し、プロトコルに従うインセンティブを与えることができます。
同様のプロジェクトには、分散型のBTCをバックにしたERC-20トークンであるt-BTCがあります。
私たちは、複数の相互運用性スキームを活用したプロトコルが 長期的に採用される可能性が高いのは、コストを削減しつつセキュリティを強化することができるためと考えています。
5.2Blockchain Engines
5.2.1 Existing Solution
このカテゴリでは、ブロックチェーンアーキテクチャを形成する様々なレイヤーをサポートする共有インフラがあります。
(例：データ層、ネットワーク層、コンセンサス層、インセンティブ層、コントラクト層、アプリケーション層）。
議論されたソリューションは、
開発者がブロックチェーンを作成する際に活用することができ、他の人との相互運用性を提供することができる
(提供されたインフラストラクチャを使用して作成されたブロックチェーンと既存のブロックチェーンの両方において）
ブロックチェーンエンジンの研究では、各ブロックチェーンの相互運用性ソリューションの最新機能に関する最新の理解を構築するために、ブログ記事、ロードマップ、アップデートの発表など、かなりのアドホックな研究が必要となりました
ほとんどのホワイトペーパーが古く、詳細が不足している
ブロックチェーンエンジン自体は最近のトピック
5.2.2 Discussion on Blockchain Engines
ブロックチェーンエンジンは、まずプラットフォームのインスタンス間の相互運用性を提供し、次に他のブロックチェーンとの相互運用性に注目します。
例えば、CosmosはTendermintベースのブロックチェーン（インスタント・ファイナリティ・ブロックチェーン）間の「無料の相互運用性」を提供し、PolkadotはSubstrateベースのブロックチェーン上での相互運用性を提供しています（例えば、ブロックチェーンをPolkadotに接続するためのツールであるCumulusを介して）。
ブロックチェーンを別のブロックチェーンのチェーン構造、デジタル署名スキーム、伝送プロトコル、検証メカニズム、コンセンサスメカニズム、トークン発行メカニズム、スマートコントラクト言語に適応させるのは複雑ですが、コネクタやブリッジを使用することで、管理しやすいアプローチになります。
それらをブロックチェーン・ルーターと考えることができ、ソース・ブロックチェーンからの出力が処理され、別のブロックチェーンの入力に変換されます。
Cosmos, Polkadot, AION, そしてARKは、他のブロックチェーンと相互作用するために、ペグされたSideChainやHTLCに似たメカニズムを利用しています。
https://gyazo.com/7077dc85b08f3bee45819868879294ad
表6では、ブロックチェーンエンジンの主な特徴を抽出して評価することで、現在の状況をマップ化しています。
ブロックチェーンエンジンは、異なるCCCPを持っている
CosmosとPolkadotはアプローチに関していくつかの違いがあります。
Cosmosでは、特定のアプリケーションに合わせたブロックチェーンを提供するという考え方です。
IBCはXCMPよりも汎用性が高く、ユーザーがゾーンをより自由にカスタマイズできるようになっています。
現在、Cosmosには125人のvalidatorがおり、validatorの数は300まで増やすことができます。
Zoneは現在約70あり、その数は増えているようです
CosmosはZoneの制限を設けていますが(各Zoneは自主管理なので) 1つのHubに装着できるZoneの数に制限があります。
CosmosはEtheruemとの相互運用が可能です。ブロックチェーン間の相互運用性 Zoneは Cosmos SDK によって提供されています。CosmosはBitcoin、の複数のPeg Zone実装をサポートしています。
Polkadotはこのカスタマイズを制限しますが、共有セキュリティ層を提供し、トレードオフのセキュリティカスタマイズを実現します。セキュリティの前提条件は、正直であると仮定したノードの量を示しています。
super majority(SM)は、少なくとも3分の2のノードが正直であることを前提としており、Byzantine fault-tolerant consensus
algorithms ((n >2/3)で要求される一般的な条件である。一方、majority(M)はノードの少なくとも半分が正直者(1/2以上)であると仮定しています。
ネットワーク上のvalidatorの数はトレードオフの関係にあり、一般的には高い方が分散化やロバスト性に優れているが、ブロック生成のためのレイテンシーが増加し、結果としてスループットが低下します。
Polkadotには約180のvalidatorがあり（約1,000に達すると予測されている）、50から200の第一レベルのParaChainをサポートすることができます。簡単に言えば、リレーチェーンはv/10個のParaChainを処理できます。
200個のvalidatorがあるとすると、Polkadotは20個のParaChainをサポートすることができ、第1レベルと第2レベルのParaChainをすべてリレーチェーンにした場合、理論的には20x20=400個のParaChainになります。
本稿執筆時点では、PolkadotはBitcoin、Tendermint、Libra、Ethereum用のブリッジを開発しています。
ParaChain間の相互運用性はSubstrateによって提供されています。
ARKには51のバリデータがあり、物理的なリソース（ARKが管理するインスタンス）を利用しています。
ARKはEthereumブロックチェーンにERC-20トークンを送受信できる。
AIONのバリデータ数、スループット、最大サブチェーンに関する情報は見つかりませんでした。
提示されたソリューションの理論的なスループットは様々です。
Polkadotのリレーチェーンは、6秒のブロックタイムで1ブロックあたり1000トランザクションをサポートしています。
コスモスの理論的なスループットは、2つのバリデータを使用し、最大数万トランザクションのTPS を達成します
64個のバリデータを使用すると、1秒間に数千件のトランザクションが発生することになります。
ARK は作業のコンセンサスの証明に依存して、51個のバリデータを使用し、1 秒間に約 18.5 件のトランザクションを達成します
ARKはARKブロックチェーンのインスタンスを管理しているため、完全な分散型ソリューションではありません。
サービスプロバイダのリソースを除いて、ブリッジチェーンの理論的な制限はありません。
スループットを向上させるために、Cosmos、Polkadot、ARKでいくつかの最適化が行われています。
AION プロジェクトは非推奨で行き詰まっているようです。
AIONは現在、Open Application Networkと呼ばれるより大きなプロジェクトの一部となってOANをサポートしています。
CosmosとPolkadotはWASM（Web Assembly）にコンパイル可能な言語でスマートコントラクトをサポートしており、開発者はGo、C++、JavaScriptなどの言語でスマートコントラクトを書くことができます。
AIONは、ドメイン固有の言語であるAION言語をサポートするだろう。
ブロックチェーンエンジンのインスタンスは、Hyperledger Fabricのチャンネルに類似した共通の接点である「connector」によって、チェーン間の相互運用性を達成します。
connectorは、Polkadot、Cosmos Network、AION、ARKであれば、それぞれ、relay chain、Cosmos Hub、AION1ブロックチェーン、ARKメインネットが対応します。
Polkadotでは、connectorは共有セキュリティを提供します。
relay chain( parachainsと外部ブロックチェーン間の通信やコンセンサスを調整するチェーン) は、パラチェーンと他のパラチェーンをブリッジに接続します。
Cosmosでは、connectorはブロックチェーンにゆるく結合されており、Polkadotよりも柔軟性が高い。
AIONのコネクタについては、意味のある配慮は抽出できなかった。
ARK では、開発性や使いやすさを犠牲にして、コネクタを一元化しているように見える。
クロスブロックチェーンの相互運用性に関しては、すべてのソリューションは、特定のブロックチェーンタイプから別のブロックチェーンタイプにトランザクションをルーティングするブリッジやアダプターに依存しています。
https://gyazo.com/fa230d9dd8c0084b7ffe3c0e0a633237
表7でPolkadot、Ethereum 2.0、Cosmosを比較しています。
Ethereum 2.0は、ブロックチェーンの相互運用性を進化させたもので、相互運用するシャードによって構成されます。
ブロックチェーンのシャーディング技術を使用して、Ethereum 2.0のスループットを向上させます。
新しい仮想マシン「eWASM」上で動作するスマートコントラクトの新しい実行環境を特徴としています。
フェーズ0では、Ethereum 2.0ネットワークのビーコンチェーンを立ち上げ、PoSを実装し、バリデータレジストリを管理します。ビーコンチェーンはテスト目的であり、機能はありません。Ethereum 1.0は引き続き運用されます。
フェーズ1では、旧来のメインチェーンとビーコンチェーンが統合され、1つの統合チェーンになります。
フェーズ2では、エーテルアカウント、トランザクション、スマートコントラクトの実行、そしてさらなる相互運用性の機能を可能にすることに焦点を当てています。
Ethereum 2.0は、スループットの面ではブロックチェーンに近いパフォーマンスを発揮するため、ベースラインとしての役割を果たすのに適しています。さらに、EthereumはdAppsと産業用ユースケースに関して最も人気のあるブロックチェーンの1つです。
PolkadotとEthereum 2.0は、それぞれBABEとRanDAO + LMD Casperというブロック生成プロトコルを持っています。
さらに、PolkadotとEthereum 2.0には、FinalityサブプロトコルであるGRANPAとCasper FFGがあります。これらのプロトコル
を実装してシャーディング機能を提供します。
Polkadotは最大100シャードを達成することができますが、Ethereum 2.0では は64枚のシャーディングをサポートしています。Cosmosはシャーディングによる水平方向のスケーラビリティはサポートしていません。しかし、共有セキュリティレイヤーは はPolkadotのものと同じように理想化されています。特に、これはゾーンが他のゾーンからバリデータセットを継承することを可能にし、トランザクションのオフロードを可能にします。
Polkadotでは、DOTトークンに依存したリレーチェーンがメインチェーンとなっています。
Ethereum 2.0のメインチェーンはBeacon チェーンで、イーサを使用しています。
CosmosのメインチェーンはCosmos Hubで、使用するトークンはATOMです。
メインチェーンの状態遷移 の関数はWebアセンブリに依存した抽象的なメタプロトコルです。
CosmosとEthereum 2.0は固定機能を利用しています。
最終的なフォールトトレランス、つまりネットワークを危うくするために必要な欠陥ノードの最小数は、1 遅延時間が異なるすべてのソリューションで、ノードの3分の1から1を差し引いた値）である。
これらのソリューションの最終処理時間は異なるが、PolkadotとEthereum 2.0はシャーディング戦略に依存していることに注意する必要がある。したがって、その最大確定量は数百万ブロックに達することができるのに対し、コスモスは1ブロックしか得られません。
PolkadotとCosmosはスマートコントラクトとステートトランザクション機能を利用しています（スマートコントラクト実行のためのインターフェイスを提供しています）。
Ethereum 2.0はスマートコントラクトのみをサポートしています。
すべてのソリューションは、強固なガバナンスメカニズム、すなわち意思決定と意思決定の実行メカニズムを備えています。
(例：ポルカドットのマルチカメラルロック投票、コイン投票 のシグナリング)。
Polkadotは技術委員会とオンチェーン・トレジャリーでガバナンスを強化している。
コスモスでは、アトムホルダーが直接投票することも可能ですが、バリデーターは自分に張り付けられたアトムを代表して投票することができます。張り巡らされたバリデータの投票を取り消すことができます。
互換性やブリッジングについては、PolkadotとCosmosはBitcoinとEthereumのネットワークと双方向のペグを持っています。
Ethereum 2.0はEthereumとの一方通行のペグがあり、EthereumユーザーのみがEthereum 2.0にEtherを送ることができます。
PolkadotもCosmosもサイドチェーンとの通信が可能です。
Polkadotはさらに基板を活用してブリッジング機能を実装し、シャード互換性を実現しています。
5.2.3Wrap up.
提供されている機能はエンドユーザーにとって望ましいものですが、ブロックチェーンエンジンは相互運用できない
エンドユーザーは既存のソリューションの中から選択しなければならず、利用可能なリソースを最適に活用することができません。したがって、参加するネットワークは相互運用性に制約があり、最終的には単一のブロックチェーンエンジンソリューションに依存することになる。
ブロックチェーンエンジンのアプローチは普遍的に受け入れられているわけではないので、断片化をなくすことはできないと主張する著者もいます。しかし、現在進行中のGRANDPA用のTendermintライトクライアントの構築作業により、PolkadotがCosmosと相互作用できるようになり、短期的にはブロックチェーンエンジンの相互運用が可能になるかもしれません。
さらに、ブロックチェーンエンジンは、ネットワークの運用を維持するためにトランザクションフィーを必要とする。
企業のブロックチェーンシステムを考えると、次のような疑問が出てくるかもしれない。
複数のブロックチェーンを使用していますか?
Cosmos は柔軟にゾーンを設定することができますが、Polkadot ではそれが難しくなります。
したがって、ブロックチェーンエンジンは公共インフラに最適なレバレッジを提供することができますが、プライベートブロックチェーンの場合は必ずしもそうではありません。
5.3 Blockchain Connectors
Blockchain Connectorカテゴリーは、Cryptocurrency-Directed Approaches、blockchian engineで構成されています。
ここでは、利用可能な研究から導き出されたいくつかのサブカテゴリについて説明します。
(Trusted Relay、Blockchain Agnostic Protocols、Blockchain of Blockchain、Blockchain Migrators)
5.3.1 Trusted Relays
Trusted Relaysは、ソースブロックチェーンからターゲットブロックチェーンにトランザクションをリダイレクトする信頼されたパーティです。Trusted Relayは対象となるブロックチェーンの発見を容易にするブロックチェーン・レジストリが存在する環境に向けられます一般的に、このようなスキームは、CB-Txが信頼されたエスクロー・パーティによってルーティングされ、許可されたブロックチェーン環境に現れます。
5.3.2 Blockchain-Agnostic Protocols
Blockchain-Agnostic Protocolsは、任意の分散型台帳技術間のクロスブロックチェーンまたはクロスチェーン通信を可能にします
Blockchain Agnostic Protocolsは、その名が示すように、分散型台帳システム間の相互運用のための技術に依存しないプロトコルを提供しますが、下位互換性を保証するものではありません。言い換えれば、既存のブロックチェーンがこのようなプロトコルを使用するためには、そのソースコードを変更する必要があります。
Hardjonoらは、Tradecoinプロジェクトの文脈で、ブロックチェーン相互運用性のためのモデルを提案しました。
その中で各ブロックチェーンは自律的システム（またはルーティングドメイン）、スケーリング可能な接続単位として見られています。 そのような 自律システムは、分散トポロジーを用いたドメイン中心の制御を行います。
クロスブロックチェーン取引を実行し、検証するエンティティはゲートウェイと呼ばれる。
一般的に、相互運用性スキームの根底にある概念的なメカニズムは、ゲートウェイが自律的で発見可能な能力を持つことです。
ゲートウェイはその後、トランザクションを対応するブロックチェーンにリダイレクトすることができる。
Kanらは、ブロックチェーンが複数のアクター(validators, nominators, surveillants, connectors)を介して、どのようにしてクロスチェーントランザクションを実行することができるかについての理論的な研究を発表しました。
validatorsは、ブロックを検証して正しい宛先に転送し、nominatorsはバリデータを選出、その後surveillantsはブロックチェーンルータの動作を監視するという流れです。
提案されたプロトコルは、インセンティブ（プロトコルに従う者に与えられる報酬）を利用して、参加者が動的な均衡状態を達成することを目的としている。(実装の詳細は記載されていない)
5.3.3 Blockchain of Blockchains.
BoBとは、「コンセンサス・プロトコルが、複数のブロックチェーンに分散したCC-dAppsに属するトランザクションを含むブロックを組織化するシステム」である。
BoBのソリューションは、開発者がCC-dAppsを構築するためのメカニズムを提供することを目的としています。
このようなシステムは、様々なブロックチェーン上でトランザクションを発行する当事者の説明責任を提供するとともに、基礎となる各ブロックチェーンの全体的で更新されたビューを提供しなければなりません。
5.3.4 Blockchain Migrators
Blockchain Migratorsは、エンドユーザーがブロックチェーンの状態を別のものに移行することを可能にします。
Blockchain Migratorsは、Notary scheemsに似たブロックチェーン上でデータ移行を実行するソリューションを集約しています。(セクション5.1.2で議論されているように、移行プロセスを仲介する集中化されたパーティが一般的に存在するため）。
現在のところ、スマートコントラクトの移行も予測されているが、ブロックチェーン間でのデータ移行のみが可能である。
Frauenthalerらは、ブロックチェーンの相互運用性とランタイム選択のためのフレームワークを提案している。
このフレームワークは、Bitcoin、Ethereum、Ethereum Classic、Expanseをサポートしており、ユーザーが 機能的要件と非機能的要件をアプリでパラメータ化します。
フレームワークは、ブロックチェーンを ランタイムは、重み付けされたメトリクスに応じて、ブロックチェーンが他のブロックチェーンにトランザクションをルートすることを可能にします。
いくつかのメトリックには、ブロックチェーンへの書き込みとブロックチェーンからの読み込みの価格、ブロックチェーンをサポートする暗号通貨とドルとの間の為替レート、ブロックを採掘する平均時間、および分散化の程度が含まれ、このようなメトリクスと、エンドユーザーによって指定されたそれらの重みに基づいて、ブロックチェーン選択アルゴリズムは最も適切なブロックチェーンを計算します。
著者らによると、別のブロックチェーンに切り替えることで、ユーザーはコストを節約し、より良いインフラストラクチャの恩恵を受けることができる（例えば、より良いパフォーマンス、より高い分散化、より良い評判）。
このソリューションは、スマートコントラクトの移行には取り組まない。
しかし、データの移行は可能です（すなわち、データはソースからターゲットのブロックチェーンにコピーされます）。
このプロジェクトは、エンドユーザーによって運営されるオープンソースの集中型アプリケーションです。
Scheidらは、異なるブロックチェーンを接続、管理、運用するポリシーベースの不可知論的フレームワークを提案している。
ポリシーは、コストやパフォーマンスを最適化するために定義できる。
データ保存に関連するコストを最小化することを選択した場合、フレームワークは書き込みコストが最も安いブロックチェーンを選択します。逆に、パフォーマンスポリシーは、トランザクションの確認待ち時間を最小化するようにフレームワークを設定することができます。著者らは、ポリシーを管理するために、OASISコンソーシアムで定義されているAAAアクセス制御を含めています。このプラットフォームはブロックチェーンに依存しないが、サポートされているブロックチェーンの詳細は提供されていない。この作品は機能的なブロックチェーン移行ツールではありませんが、ブロックチェーン移行に必要な柔軟性を可能にしています
Fynnらは、スマートコントラクトを別のブロックチェーンに一貫して切り替えるための抽象化を提示しています
トランザクションで必要とされるものを、ターゲットのブロックチェーンに移動して実行する。
著者らはこのような抽象化をMove 操作と呼びます。
この操作は次のように動作します: まず、ソースブロックチェーン上のスマートコントラクトをロックします。プロトコルは、ターゲットブロックチェーン内のスマートコントラクトを再作成します。
この方法では、任意の状態を ブロックチェーン間で 例えば、ターゲットブロックチェーン上にトークンを作成することで、暗号通貨を転送することができます。ソースブロックチェーン上のロックされたトークンによってバックアップされている（ペグされたサイドチェーンに似ている）。
この方法は、EthereumとHyperledger Burrow（Ethereumベース）でテストされました。
このソリューションは、同じクロスブロックチェーンのスマートコントラクトが同じ仮想マシンを利用することを前提としており、これは制限される可能性があります。
さらに、このようなソリューションをデプロイするには、Solidityの変更と、Ethereum上でのソフトフォークが必要になります。
5.3.5 Discussion on Blockchain Connectors.
このセクションでは、Blockchain Connectorsのカテゴリとそのサブカテゴリを定義しました
( trusted relays, blockchain-agnostic protocols, blockchain of blockchains, and blockchain migrators)
各サブカテゴリへの主な貢献をレビューしました。
クロススマートコントラクトの機能を証明するソリューションが登場しているが、まだ開発中のようです。
https://gyazo.com/a0c36cf9186f99a79cfa3f8beb447072
表8は各ソリューションを要約し、対応するサブカテゴリに集約しています。
提示されたソリューションの中央集権化については、ほとんどすべてが分散型モデルを採用しています。
許可されたブロックチェーンソリューションは、関与するすべての参加者が特定されているため、柔軟性の低いモデルを選択しています。
trusted relays
特に、trusted relaysは、事前の合意に基づいてP2Pで行われる接続を承認します。
しかし、Abebe氏の研究にはいくつかの制限があります。
相互運用ネットワークは、お互いのアイデンティティと構成を事前に知っておく必要があり、静的である。
発見サービスはブロックチェーンレジストリを使用して実装することができ、そこではネットワークを追加したり削除したりすることができます（マイクロサービスのパブリックレジストリに似ています）。
trusted relaysでは、レプリケーション（検閲攻撃のリスクは軽減されるが消去されない）を除けば、悪意のあるリレーサービスを最小化するメカニズムが何であるかは完全には明らかではない。
Hyperledger Cactusは、（分散化された）信頼されたブロックチェーンレジストリが展開され、信頼された当事者のオーバーレイが公的なエスクロー当事者に置き換えられることを考えると相互運用性を実現する真のイネーブラーになる可能性があります
したがって、Cactusは信頼されたリレーから半信頼されたリレー、あるいは信頼されないリレーへの移行を行うことができます
Blockchain Agnostic Protocols
Blockchain Agnostic Protocolsに関しては、それらのプロトコルが、以下のプロトコルとの相互運用性を提供するために、より良い位置にあると主張しています。既存のブロックチェーンとこれからのブロックチェーンがありますが、ほとんどのブロックチェーンは下位互換性を付与していません。
BoB
Hyperserviceは、ステートレスなスマートコントラクトの概念を導入することで、完全なdAppのアトミック性を達成しようとしています。ステートレス・スマートコントラクトを使用することで、CC-dAppは有効なブロックを使用して、コントラクトのクリーンな状態をロードすることができます。CC-dAppが利用するブロックチェーンのフォークを部分的に解決することができますが、このコンセプトを適用することで、スマートコントラクトの実行をコンセンサス層から切り離す方向性が見えてきます。
Overledgerは、クロスブロックチェーン・アプリケーションの状態として解釈されるメッセージのソートされたリストです。
これはブロックチェーンの相互運用性への刺激的なアプローチですが、このソリューションはプロプライエタリであり、より複雑なソリューションへのコミュニティの取り組みを妨げています
CAPERは、異なる利害関係者が相互作用する協調的なシナリオの中で、内部取引に機密性とプライバシーを提供しようとしています。クロスアプリケーションのトランザクションは見ていて興味深いが、データプライバシーの文脈では、Fabricのプライベートデータとしての機能は、この問題を解決する可能性がある。
blockchain migrators
blockchain migratorsのアプローチは、企業のニーズに応えるものである。
提示された2つのソリューションは、パブリックブロックチェーンの小さなセットにまたがってデータのポータビリティを提供することしかできません。
スマートコントラクトを介してイベントの連鎖を再現するには、スマートコントラクトのトランスレータ機能が必要であるため、現在のところ不可能である。
提示されている作品のほとんどが実装されておらず、研究分野がまだ始まったばかりであることを示しています。
いくつかのアプローチは中央集権的なアプローチをとっており、特に信頼できる当事者間の直接接続を必要とするものや、ブロックチェーンの実装を移行する方法などが挙げられます。
Blockchain Connectorsの制限事項は以下のようになります。
ほとんどのソリューションがフォークをサポートしていない上に、フォークのための最終的な解決策も提案していこと
特に、この問題はパブリック・ブロックチェーンを対象としたソリューションでは、より悪名高いものとなる
フォークが定期的に発生しているわけではなく、いくつかのソリューションは問題の迅速な分析を提供し、その重要性を認めています。しかし、これはCC-dAppの信頼性に影響を与える問題であり、フォークへの対応はまだ未解決の課題です。
例えば、Hyperservice で使用されているプロトコルは、状態の更新をすべて スマートコントラクトは、dAppが早期に終了した場合、つまり原子性を付与していない場合に使用します。原子性を持たない場合 を保証するために、フォークが発生した場合、クロスブロックチェーンアプリケーションを一貫性のない状態に強制します。
これは、プロジェクトの目的である機能的なCC-dApを危険にさらす可能性があります。
同じ問題がOverlederやBlock Colliderにも当てはまります。
このようなAPIの標準化は、後方視的な標準化開発のための実りある分野であると結論付けたくなるかもしれないが、ブロックチェーン固有のAPIは、根本的に異なる技術的実装の間でうまく一般化される可能性は低い。
Blockchain-agnostic protocolsはAPIよりも標準化される可能性が高く、歴史的にはHTTPやTCP/IPファミリーのような標準化の取り組みが成功している。
6 DISCUSSION, USE CASES AND RESEARCH QUESTIONS
ここでは、我々が抽出した各ブロックチェーン相互運用性カテゴリの包括的なまとめと、我々のブロックチェーンの相互運用性に関する考慮事項を紹介します。その後、ユースケースを提示し、私たちが提案した研究上の質問への回答で終わります。
6.1 Discussion
本稿では、まず第5.1節でCryptocurrency-Directed Approachesを紹介し、その特徴を強調した。
その代わりに、ここ数年で様々な相互運用性のアプローチが登場し、その多くはブロックチェーンの相互運用性を向上させることを一般化することを目的としています。
大別した3つのカテゴリーのうちCryptocurrency-directed Approachesはそこそこだが、他の2つは新興のソリューションである。
CCBPを提供するBlockchain Connector
エンドユーザーがベンダーのロックインを犠牲にしてカスタマイズされた相互運用可能なブロックチェーンを作成することを可能にするBlockchain Engine
特にCosmos、Polkadot、Ethereum2.0
Blockchain Engineとblockchain conectorsは、中期的にはブロックチェーン間だけでなく、他の分散型台帳技術や企業システム間の相互運用性を可能にします。これにより、ブロックチェーンの相互運用性の標準化が促進されます。
ブロックチェーンが成熟する間 業界では、この技術をビジネスプロセスに組み込む傾向があります。
そして、大量採用が続くと予測しています。
Cryptocurrency-directed Approaches
Cryptocurrency-directed Approachesは、現実世界の問題 (投資家や開発者に必要な相互運用性の機能を提供し、パブリック・ブロックチェーンにまたがって普及する問題)に対し実用的なソリューションを提供しているため、産業界や学術界で最も引用されています。これらが最初に登場したソリューションであるため、驚くことではありませんが、成功しないものもあるかもしれません。
Sidechainとエスクローパーティ（スマートコントラクトやHTLCによって強制される）に依存したプロトコルの融合が、パブリックブロックチェーン間の相互運用性に最も適した解決策であるように思われる。
我々は、そのような提案の柔軟性、分散化、セキュリティが安全な相互運用性のために利用できることを主張する。
Blockchain Engine
Blockchain Engineは、同じプラットフォームのインスタンス間でビルトインの相互運用性を提供しながら、ブロックチェーンの採用を促進することができ、一方、前述のソリューションのバリエーションは、Blockchain Engineを他のブロックチェーンに橋渡しするために使用することができます。
CosmosやPolkadotのようなBlockchain Engineは、コンセンサスエンジンと共有セキュリティ層を提供する一方で
ブロックチェーンを構築するBoBは、異なるインフラを使用してソリューションを開発することを目指しています。
特に、CosmosとPolkadotは、それぞれTendermintベースのブロックチェーン、およびSubstrateベースのブロックチェーンの作成のみをサポートしているため、同質性に向かって進歩する可能性があります。
これらは、主にその技術に依存するチェーン上での相互運用性の機能、および他の望ましい機能（セキュリティの共有層、分散化、ガバナンス、より優れたスケーラビリティ）を提供するが、エンドユーザーの選択は、特定の実装に縛られることになるでしょう。逆説的に言えば、このようなソリューションはデータや価値のサイロ化に貢献する可能性があります。
この事実にもかかわらず、bridges/adaptersを構築することで、この問題は緩和されると主張することができます。
blockchain conectors
特にblockchain migrators、BoBは、ブロックチェーンの ユーザー中心のブロックチェーンにとらわれない視点で進歩しており、CC-dAppsを可能にしています。エンドユーザーがソリューションの展開をコントロールできるようになり、これら2つのカテゴリは、notary schemesと考えることができます。
private blockchainsを接続するための最も適切なソリューションは、Blockchain-Agnostic Protocolsを使用することです。 しかし、これまでのソリューションはすべて、採用された通信プロトコルを統合するために適合させなければならないため、下位互換性はありません。これを克服するための短期的な解決策としては、trusted relaysを使用することになるでしょう。
trusted relaysがベンチャーになるための興味深い方法は、エスクローパーティを分散化することである。
つまり、信頼されたバリデーターのセットからパブリックノードのネットワークへの分散化です。
まとめると、この調査では、以下のように考えることができます。
trusted relaysとBlockchain-Agnostic Protocolsがprivate blockchainsを接続するのに適したソリューション
Sidechain、スマートコントラクトベースのプロトコルがパブリック・ブロックチェーン間の相互運用性を解決するのに適したソリューション
パブリック・ブロックチェーンとプライベート・ブロックチェーンをどのように接続するのか？
Blockchain Engineで動くブロックチェーンのネットワークは、blockchain conectorsを使って活用することができます。
例えば、CosmosとInterledger Protocol (ILP)の間には、相乗効果の可能性があります
(ユーザーがCosmosゾーン内で不換通貨（例えばドル）を使ってアプリ内決済をしたい場合、インターレッジャープロトコルを決済レールとして頼りにすることができます)
crpytocurrencies を使用して支払いを行う場合 (例: Bitcoin)、interledger routerは支払いチャネル(例: ライトニングネットワーク）にトランザクションをルーティングすることができ、より信頼性の高い相互作用を提供します。
このエコシステムをプライベート・ブロックチェーンに接続するためには、ブリッジを開発する必要があります。
このようなブリッジを信頼できるものにするためには、パブリック・ブロックチェーンとプライベート・ブロックチェーンの両方のコンセンサスに参加するバリデータ・ノードのグループをオーバーレイ・ネットワークを介して選出することが考えられます。このようにして、クロスチェーンとクロスブロックチェーンのトランザクションを承認することができる。
HSLand DAMLのようないくつかのクロスチェーンプログラミング言語が登場していることは特筆に値する。
DAMLは、基礎となるブロックチェーンを抽象化し、HSLと同様にその上に高レベルの抽象台帳を公開することで、統一されたブロックチェーンプログラミングモデルを提供します。DAMLは異なる統合度合を持っています。ターゲットプラットフォーム上のアプリケーションとしてのDAMLと、DAMLランタイムエンジンがトランザクションを検証する統合です。
このような言語でコンパイルされたプログラムは、BoBプラットフォームの上で実行することができます。
この議論の結論として、ブロックチェーンの開発がサイロで行われてきたことを読者に想起させます。
2017年の時点でブロックチェーンの相互運用性のための新しいソリューションが登場し始めており、おそらく驚くべきことではないが、そのようなソリューションもサイロで採用されている。
現在では暗号資産指向の手法が一般的ですが、とブロックチェーンコネクターには特に力を入れています。
6.2 Supporting Technologies and Standards
https://gyazo.com/fcee02dd2ea6ce800e0683c1770cf3da
提示されたソリューション以外にも、ブロックチェーン相互運用性のサポートと標準化に向けた取り組みがあります。
ブロックチェーン相互運用性の標準化は、すべてのブロックチェーンに共通する「標準化されたトランザクションフォーマットとシンタックス」と「標準化された最小操作セット」を作成しようとしています。
まず、ブロックチェーンの相互運用性を促進する間接的な貢献を紹介し、次に既存の標準を紹介する。
cross-blockchain data storage solutionは、アプリケーションの相互運用性を達成するための実現可能なソリューションとなり、それゆえ、アプリケーションは1つのブロックチェーンに依存しています。
すでにいくつかのdAppは、ブロックチェーンに隣接した共通のストレージを作成するためにInterPlanetary File System (IPFS)を活用しています。IPFSは、分散ファイルシステムに任意のデータを格納して配信するためのピアツーピアネットワークを提供します。
Astreaは、投票ベースの汎用分散型オラクルです。
分散型オラクルは、ブロックチェーンに信頼できる外部の真実のソースを提供し、データのポータビリティを促進します。
真理の共有ソースがあれば、組織横断的なワークフローを簡素化することができます。
Hyperledger Avalonは、メインブロックチェーンからの集中処理をオフチェーンチャネルに延期し、中央集権的でありながら信頼できるオラクルをサポートします。(信頼された実行環境を使用することで)同じデータを複数のブロックチェーンで使用できるため、相互運用性を促進します。
Hyperledger IndyやHyperledger Ariesのようなオープンソースプロジェクトは、デジタルアイデンティティと自己主権的アイデンティティの分野で活動しています。
自己主権的アイデンティティの中心的な概念は、分散型識別子（DID）とverifiable credentialsである。
分散型識別子は、ゼロ知識証明（ZKP）メカニズムを使用して作成、管理、共有することができる。
verifiable credentialsは、特定の DIDを使用して、検証可能なプレゼンテーションを介して、保有者が主張を証明することを可能にする。
Verifiable presentationsは、DIDによって特定されたサブジェクトに割り当てられた属性を記述する。
対象者は、個人、機関、または物であることができる。一般的に、対象者はクレデンシャルの保持者でもあるが、必ずしもそうとは限らない。検証可能なクレデンシャルに合わせて分散型識別子標準を推進することで、ブロックチェーン間での ID ポータビリティを実現し、ブロックチェーンの相互運用性への道を開くことができます。
Token Taxonomy Initiative は、デジタルトークンの標準化に特化したコンソーシアムです。
トークンの分類階層に従ってトークンの動作、プロパティ、制御インターフェースを識別するための標準を提案しています。
このプロジェクトは、アプリケーション開発者がブロックチェーンに関係なくトークンと対話するための標準コードセットを利用することを可能にします。プラットフォームを利用することで、ブロックチェーンの相互運用性にインセンティブを与えることができます。
一般的な相互運用性という意味では、Ethereum ERCは事実上の標準となっています。
例えば、ERC20トークンはユーティリティ・トークンのための標準化されたスキーマを定義し、ERC1400はセキュリティ・トークンを定義している。
Treatらは最近、分散元帳の相互運用性に関する特許を申請した。
この特許は資産移転に向けられたもので、オリジンメモリ（オリジンブロックチェーンを表す）とターゲットメモリ（ターゲットブロックチェーンを表す）を持つシステムを含む。
ブロックチェーンは「インターロップ回路」を介してリンクされており、多階層の交換を実装しています。
著者らは、「相互運用性を実装する」という目的のために、デジタル暗号資産（暗号通貨など）を特徴づけることで、ブロックチェーンの相互運用性に取り組んでいる。このような間接的な貢献は、業界標準の開発への道を開く。
Hyland-WoodとKhatchadourianは、国際的なブロックチェーン標準をまとめています。著者らは、将来の相互運用性標準のための3つの分野を提案しています。
BPMNにおける企業システムにブロックチェーンを統合するための道を開くスマートコントラクトの表現
ブロックチェーン間のアイデンティティを容易にするための分散型識別子
ブロックチェーンシステム間のデータ境界を減らすためのインターレジェントプロトコル
これら3つの分野では、ブロックチェーンの相互運用性に関する具体的な課題に取り組んでいます。
具体的には、Archimateなどの標準的なエンタープライズ・モデリング言語を使用したクロスブロックチェーン・スマートコントラクトの実行です。またはBPMNのように、業界からの大量採用を促進する可能性があります。
ブロックチェーンの新規性に内在するリスクと文書化の不足が、企業の採用を遅らせる要因となっている。
第二の分野については、分散型識別子は異なるブロックチェーン間でのアイデンティティのポータビリティを促進することができます。最後に、Interledger や Overledger のようなクロスブロックチェーン通信プロトコルの開発と標準化は、同様に大量採用に貢献することができます。ISO技術委員会307は「ブロックチェーンと分散型台帳技術の標準化」48に向けて活動していますが、まだ何の標準も作成していません。サブグループ7（ISO/TC/SG7）は、特に相互運用性に焦点を当てています。
既存の標準では、現在第5版のEnterprise Ethereum Client Specificationが検討されている。
ブロックチェーンの相互運用性の標準化に取り組んでいる他のプロジェクトには、IEEE 2418.2-2020規格を通じて
IEEE Blockchain InitiativeとIEEE Standardsがある。欧州委員会によるEU Blockchain Observatory & Forumは、1)欧州におけるブロックチェーン活動の監視、2)ブロックチェーン知識のソースの管理、3)情報共有のためのフォーラムの作成、4)ブロックチェーンにおけるEUの役割に関する提言の作成を目的としています。同機関は、政府内での採用だけでなく、標準規格の数も増加する可能性があると指摘しています。
他の当局は、セキュリティ・トークンを分類し、クリプト・アセットのガイダンスを提供しています。
WoodとKhatchadourianは、W3Cが、以下を定義するのに最適な標準定義組織であると提案している。
ブロックチェーンのコネクタプロトコルは、そのような組織がブロックチェーンの位置付けを「広める」ことを含む場合
ワールドワイドウェブの「定義」。
著者らは、ISO、IEEE、IETF、IRTF、OMGなどの他の組織は、ブロックチェーンの相互運用性に関する将来の標準化開発を模索する上で、W3Cほどの立場にはないと考えている。
6.3 Use Cases with Multiple Blockchains
業界では、未だにブロックチェーンを利用したユースケースに1つのブロックチェーンのみを適用しています。
そのため、複数のブロックチェーンを利用したユースケースは少ないと予想されます。
しかし、既存のリソースによると、複数のブロックチェーンを利用したユースケースにはかなりの関心があるようです。
技術が成熟する限り、斬新で破壊的なユースケースが見つかるかもしれません。
暗号通貨関連技術に関連したユースケースの例としては、cross-chain payment channels、efficient multi-party swaps、point of saleとutility tokens、DEXなどが挙げられる。
注目すべきユースケースとして、HLTC技術を活用して、ユーザーが異なるブロックチェーンからの資産を他のユーザーと直接交換できるようにするDEXに注目しています。Blockchain enginesはDEXを実装し、ユースケースとして分散型銀行を予測しています。例えば、分散型取引所BinanceはCosmos SDKを利用しています。
ブロックチェーンゲームプラットフォーム、ステーブルコインはPolkadotで実装されています。さらに、ブロックチェーンエンジンは、企業によるブロックチェーンの採用を刺激することができます。
Cosmosを使用することで、zoneは企業システムのブロックチェーンバックアップ版として機能し、従来は組織やコンソーシアムによって運営されていたサービスが、特定のzone上でアプリケーションのブロックチェーンインターフェースとして実行されるようになります。
一部の著者は、CBDCのためのIoBアプローチを提案していますが、これはBlockchain enginesのソリューションで実現できます。
blockchain connectorsに関しては、企業や個人がブロックチェーンに投資する際のリスクを軽減できるソリューションとして、Blockchain migratorsが注目しています。リスクを軽減することで、投資家はより高い投資収益率を期待することができる為です
ブロックチェーン相互運用性プロジェクトであるHyperledger Cactusには、Blockchain migrator機能が搭載されており、ブロックチェーンを運用しているステークホルダーのコンソーシアムが、その資産（データ、スマートコントラクト）を別のブロックチェーンに移行することができます。
その他のユースケースとしては、ブロックチェーンをまたいだ資産の移動、コインのデータのエスクロー販売、ステーブルコインを不換通貨や暗号通貨にペッグすること、アクセス制御リストを用いたヘルスケアデータの共有、既存の食品トレーサビリティソリューションの統合、エンドユーザーのウォレットアクセス制御などが実現可能です。
より一般的には、BoB・アプローチを活用して、現在の問題を解決することができます。
著者らは、偶発的な障害やセキュリティイベント（特に内部データ漏洩）がエンドユーザーへの問題であると主張している。
この問題は、十分な信頼性を提供していない個々のクラウド・プロバイダーの上に、追加のセキュリティと信頼性のための「クラウド・オブ・クラウド」を作成することで緩和することができます。
BoBのアプローチを利用して、サービスの信頼性とセキュリティを高めることができると主張することもできます。
データの収集、保存、アクセス、処理は、業界を超えて一般的に行われているだけでなく、繁栄に貢献に必要不可欠なものでもあります。多くの場合、ユースケースには、異なるニーズを持つ複数のステークホルダーが存在し、異なる組織の境界に属している。これらのステークホルダーは、データへのアクセス権が異なる場合があります。このように、開発者は使用しているブロックチェーンの機能をステークホルダーの（時には相反する）ニーズに合わせて適応させます。
将来的にブロックチェーンを変更したいと思うかもしれないので、開発者はブロックチェーンの選択に柔軟性を求めていることを強調しておきましょう。
この特別なニーズは、クラウド環境でも発生するベンダーのロックインの可能性に関連しています。
このような柔軟性の必要性は、lockchain migratorsや複数のブロックチェーンを活用することで実現することができます。
アクセス制御リスト、食品トレーサビリティソリューション、エンドユーザーのウォレット認証/認証、サプライチェーン、医療サプライチェーン、メディア、サイバーセキュリティ、ビデオゲームなどのヘルスケアデータ共有に関するユースケースも提案されています。
6.4 Answers to the Research Questions
本節では、第 3.1 節で提示された研究課題に対する回答を提供する。
(1) ブロックチェーン相互運用性ソリューションについて、産官学の双方から、現在の状況はどうなっているのか？ つまり、ブロックチェーン相互運用性ソリューションの現状はどうなっているのか？
ブロックチェーンの相互運用性に向けた最初のステップは、トークン（例えば、クリプトカレンシー）の交換を可能にするメカニズムの作成である。
私たちはそのようなソリューションを、暗号資産指向の相互運用性アプローチとして分類しました（5.1）。
このカテゴリは、Sidechain（5.1.1）、Notary Schemes（5.1.2）で構成されています。
このようなカテゴリには、Side Chains(5.1.1)、Notary Schemes (5.1.2)、HTLCs(5.1.3)、Hybrid Solutions(5.1.4）があります。
新しいブロックチェーン相互運用性のアプローチは、Blockchain Engine（5.2）とBlockchain Connectorsです(5.3）。
Blockchain Connectorsは、Trasted Relays(5.3.1）、 blockchain-agnostic protocols (5.3.2）、BoB（5.3.3）、blockchain migrators（5.3.4）の4つのサブカテゴリに分類されます。
(2) ブロックチェーンの相互運用性のための技術的な要件は、現在のところ満たされているのか？
この研究課題については、2つの見解があります。
現在、ブロックチェーンの上に構築されたアプリケーションをサポートするのに十分成熟していると考えられるブロックチェーンがいくつか存在するという見解とブロックチェーンに関する相互運用性を実現するためには、必要なインフラストラクチャとそれを促進する技術が必要だという見解です。
特に、DIDや、verifiable credentials、CCCp、ブロックチェーン・スマートコントラクトの表現は、ブロックチェーン相互運用性に対するかなりの障壁を取り除き、ブロックチェーン相互運用性の標準化とソリューションの可能性を促進することができます
結論として、ブロックチェーン相互運用性のための重要な要件は、現在のところ満たされています。
(3) ブロックチェーン相互運用性から来るバリューチェーンを可能にする実際のユースケースはあるのか？
3つ目の研究課題については、ブロックチェーンの相互運用性が重要であるだけでなく、この技術の生き残りのためにも重要であると擁護する著者もいます。
標準化はブロックチェーンの採用に道を開いています。
「前向きな相互運用性の標準化は、標準化を成功させ、業界の成長を促進する可能性が高い」と考えられています。
逆に、標準化は大量採用のための必要条件であり、開発が進められています。
複数のブロックチェーン相互運用性ソリューションを考えると、Blockchain EngineとBlockchain Connectorsの両方があり、そのうちのいくつかは業界でかなりのウェイトを占めています。これは非常に可能性の高いシナリオであると考えています。
6.3では、クロスブロックチェーン技術の恩恵を受ける可能性のある複数のユースケースを公開し、愛好家だけでなく企業による採用を促進することができます。結論としては、今後数年間で信頼性の高いソリューションや標準が登場するだけでなく、ブロックチェーンの採用が着実に増えていくことを想定しています。
---
相互運用性は、価値を高めるものであり、成熟したキーファクターであるため、最終的にはこの技術の存続を決定することになります。
収集し分析したエビデンスに基づいて、ブロックチェーンの相互運用性が学界と産業界の間で注目を集めているこの研究分野への注目度が高まることが予想されます。
6.5 Open Issues and Challenges
このセクションでは、ブロックチェーンの相互運用性と、より一般的な意味でのブロックチェーンの採用に関するオープンな問題と課題を提示します。
今日、分散型アプリケーションを構築するために利用可能なソリューションは、相互運用性に欠けており、スケーラビリティを妨げています。
Liuらが指摘しているように
"異なるブロックチェーン上の実行を調整するために信頼された権限を持つ者がいない場合、完全に信頼されない方法で正しい実行を強制することは非常に困難です。
この分野における最近の進歩は、興味深いものであり悪名高いものであり、相互運用性を現実のものとしていますが、既存の作業の多くはほとんどが概念的なものであるため、理論と実践の間にはまだギャップがあります。
膨大な量のブロックチェーン・プラットフォームを考えると、ソリューションと相互運用性へのアプローチに関する断片化は、例えばIoTシナリオにおいて強く存在しています。
例えば、特定の目的に合わせて調整された複数のプラットフォームの組み合わせは、パブリック、プライベート、またはコンソーシアムである可能性があり、ワークフローを管理するためのオーバーヘッドが追加されます。
特に、複数のブロックチェーンが特定のアプリケーションにサービスを提供している場合、この懸念が強まる。
ブロックチェーンのスケーラビリティに関しては、パブリック・ブロックチェーンとプライベート・ブロックチェーンの両方において、現在のパフォーマンスを改善することで、IoBを実現することができます。
暗黙のコンセンサスやデータシャーディングのような技術は、トランザクションのスループットやストレージを改善することができます。しかし、ブロックチェーン・シャーディングでは、ブロックチェーン間のトランザクションのルーティングや検索、資産参照などの問題を解決する必要があります（discoverability problemとしても知られています）。
クロスチェーンのdAppをサポートするために、異なるブロックチェーンからのトランザクションを調整することは困難です。
(他のブロックチェーンに依存していたトランザクションを元に戻すことは面倒な問題になります)。
特に、別のものに依存していたトランザクションを戻すことは、特に異なるブロックチェーンからの異なるトランザクションの最終的な処理を考えると、面倒な問題になることがあります。
いくつかのソリューションでは、このような課題を克服するための仕組みが提案されている（BoB）。
殊勝なアプローチではあるが、これらのソリューションが任意に複雑なクロスブロックチェーンのdAppに適用できるかどうかはまだ明らかではない。このアプローチの実現可能性を確認するためには、さらなる研究が必要である。
いくつかの著者は、セキュリティ、信頼、機密性、データプライバシーの問題など、GDPRに関連する問題を強調している。
特に、セキュリティの脅威は、複数のブロックチェーンの存在と複数の管理者の可能性によって悪化します。プライバシーに関しては、著者らは、ユーザーがブロックチェーンから自分のデータを削除するように求めることができる「忘却権」の問題点を強調している。現在のところ、ほとんどのブロックチェーンはこの要求に対応できる効果的なメカニズムを提供していません。
ブロックチェーンの細かいアクセス制御は、情報漏洩や機密性のリスクを最小限に抑えるための重要な要件として指定されています。ブロックチェーンの相互運用性は、単一のブロックチェーンへの依存性を減らし、結果的にリスクを軽減しますが
( ブロックチェーンが攻撃された場合）固有のリスクを排除するものではありません。
マルチプル・ブロックチェーン・アプローチは、その部分の合計よりも複雑であることを強調しておく価値があります。
これはガバナンスに課題を追加します：民間コンソーシアムがブロックチェーンコネクターを自由に使用してシステムの相互運用（分散化および／または分散化）を行うことができるのに対し、パブリックブロックチェーンによってサポートされているコミュニティプロジェクト内では、ガバナンスモデルは一筋縄ではいきません。
要するに、ブロックチェーンの相互運用性に向けた最も関連性のあるオープンな問題は以下の通りです。
- 理論と実践のギャップ。
- Fragmentation
- Discoverability
- プライバシーとセキュリティ
- ガバナンス
とはいえ、セキュリティ、プライバシー、スケーラビリティはブロックチェーン空間で改善すべき最も顕著な分野であることに変わりはありません。
7 RESEARCH DIRECTIONS
新しいツール、フレームワーク、標準的な提案、さらにはプログラミングモデルまでもが登場しており、さらなる開発が必要とされています。PolkadotやCosmosのようなプログラミングモデルは、開発者がブロックチェーンを効果的に作成したり他のブロックチェーンに接続することができる方法を提供しています。
ILPやUIPなどのプロトコルは、CB-Txを可能にします。
HSLやDAMLなどのプログラミング言語は、異なるブロックチェーンモデルを埋め込むことを目的としており、CC-dAppsのための抽象化を提供しています。
ブロックチェーンの相互運用性ソリューションをパブリックまたはプライベートのブロックチェーンに利用することにはそれなりの理由がありますが、それらを接続するために実際に利用できるソリューションはほとんどありません。
例えば、マルチチェーンはビットコインに接続することができますが、機能は限られています。
したがって、パブリックブロックチェーンとプライベートブロックチェーンを双方向に接続することは、依然として未解決の問題である。
パーミッションのある台帳とパーミッションのない台帳をまたいだ双方向通信がもたらす問題の1つは以下の通りです。セマンティックな互換性を実現します。
技術的な相互運用性は、相互運用性を実現するための技術的な基盤を提供するが、それ自体が意味的な相互運用性を付与するものではない。
そのため、次のようなギャップがあります。
新しいユースケースを可能にするために、ブロックチェーンの両方のタイプを効果的に組み合わせるにはどうすればいいのか？
どのようにしてソリューションを、関係するすべてのステークホルダーの目標に適合させるのか？
ビュー統合のようなディシプリンは、その答えを提供するのに役立ちます。
ビュー統合とは、同じビジネスプロセスのビューを一つにまとめて統合するプロセスです。
異なるブロックチェーンに参加している利害関係者の異なるビューを統合することで。
ブロックチェーン採用のもう一つの大きな障害は、その開発のスピードの速さである。
ブロックチェーンの相互運用性標準の開発は、下位互換性に関するより柔軟な方法を提供する可能性があります。
本研究では、本研究の成果と明らかになった課題と課題を踏まえ、以下のような研究の方向性を提案する。
ブロックチェーンの相互運用性を可能にするためのアーキテクチャの研究、クリプトカレンシー指向
相互運用性アプローチ、ブロックチェーンエンジン、ブロックチェーンコネクター、サポート技術、標準、利用
のケースなどを紹介しています。
ブロックチェーン相互運用性のためのアーキテクチャ（セクション 2.4 )
ブロックチェーン相互運用性の成熟度モデルを定義し、様々な層（技術的、意味的、組織的など）での相互運用性をモデル化する。
さまざまなステークホルダーに応じた、さまざまなタイプの相互運用性に関するさまざまな見解をモデル化する。
(例：クロスブロックチェーンdApp上のプロバイダの技術的な見方と、同じクロスブロックチェーンdApp上のエンドユー ザーの意味的な見方)
ブロックチェーン相互運用性のセマンティクスを、例えば、ビュー統合の研究領域を探索することによって研究する。
クリプトカレンシー主導の相互運用性アプローチ（セクション5.1）
許可されたブロックチェーンは、スケーラビリティとプライバシーを向上させるために、サイドチェーンから利益を得ることができる方法の研究。
不換紙幣交換、分散型取引所でのより高い流動性を可能にするプロトコルを開発する。
逆に、中央集権型取引所のプライバシーとセキュリティのレベルを向上させる。
ハイブリッドソリューションの研究と開発 ブロックチェーンエンジン(5.2)
既存のブロックチェーンシステムとブロックチェーンエンジンの統合。
ブロックチェーンエンジンが、許可されたブロックチェーンと許可されていないブロックチェーンの架け橋となる信頼性の高い相互運用性スキームをどのように提供できるかを研究する。
ブロックチェーンエンジンを中央集権型システムと分散型台帳システムの両方に接続する
（例：Polkadotを接続する をVisaに変更)。
ブロックチェーンコネクター（セクション5.3）
公開ブロックチェーンと統合することで、信頼されたリレーの信頼を分散化する
（例えば、状態 定期的にパブリック・ブロックチェーン)。
ブロックチェーンに依存しないプロトコルを既存の台帳に簡単に適応させる方法を研究します。
信頼性の高いブロックチェーンベースのアプリケーションの進歩として、ブロックチェーンのブロックチェーンアプローチを探求する。
クロスブロックチェーン分散型アプリケーションにおける原子性と一貫性の保証を改善します。
公開台帳と許可された台帳をまたいだブロックチェーンの移行を探求する。このような移行スキームは分散化され、利害関係者によって課される機能的・非機能的な要件に適応することができます。
信頼されていないリレーを介したブロックチェーンの移行を検討する。
非信頼リレーを介したブロックチェーン移行を探る
(プロトコルに従ったパブリックエスクローノードのセットを使用するなど）。
複数のブロックチェーン管理のためのフレームワークを開発する。そのようなフレームワークは、複数のステークホルダーのニーズに対応し、信頼を分散させるべきである。
サポートする技術や標準、ユースケースなど（第6節）
ブロックチェーン相互運用性のプログラミング言語、支援ツール、標準に関する研究。
クロスブロックチェーンプログラミング言語やフレームワーク、分散化された識別子や検証可能なクレデンシャル、企業ブロックチェーンのためのブロックチェーン相互運用性の標準などが含まれますが、これらに限定されるものではありません。
複数のブロックチェーンを使用した新しいユースケース、「価値レベル」の相互運用性を探求します。
暗号通貨ベースの相互運用性アプローチ、ブロックチェーンエンジン、ブロックチェーンコネクター間の相乗効果を研究します。
ブロックチェーン相互運用性のセキュリティ面を研究します。
8 CONCLUSION
本論文では、ブロックチェーンの相互運用性に関する体系的な文献レビューを行った。
系統的に分析した。45のブロックチェーン相互運用性ソリューションに対応する80のドキュメントを比較、議論しました。
グレーを含むことで のようなブロックチェーン相互運用性の研究領域に関する本質的な制限を打ち破ることを期待しています。業界の中でもかなりの存在感を示している。
各ソリューションを方法論的に探求することで、本研究は興味深い の洞察は、3つのカテゴリーに分散しています。クリプトカレンシーベースのソリューション、ブロックチェーンエンジン、ブロックチェーン コネクタです。
サイドチェーンやHLTCソリューションが業界で牽引しているにもかかわらず、ブロックチェーンの相互運用性は、クリプトカレンシーを指向したソリューションだけではありません。
2017年以降、新たなアプローチが台頭し始めました。
ブロックチェーンコネクターは、大多数のユースケースに適応した多様なソリューションを提供しています。
これらは、クロスブロックチェーンのdAppsを作成するために使用される可能性が高いです。
ブロックチェーンエンジンは、簡単に作成でき、カスタマイズ可能なブロックチェーンを活用することで、短期的・中期的には業界で採用される可能性が高いです。